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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). All Rights Reserved. 


Abstract 


This document defines the procedures for IANA to administer and 
maintain the Object Identifier (OID) tree under the Remote Monitoring 
(rmon) root. This memo also documents the currently assigned values. 


1. Introduction 


The RMONMIB Working Group so far has maintained its own registry for 
OID assignments for new MIB modules under the root OID for rmon 
[RFC2819]. This has worked reasonably well, although errors had to 
be corrected at a late stage one or two times, and a few now defunct 
assignments have been made as well. 


It is also a somewhat non-standard way of doing things, because 
normally a new standards track MIB module will get a MIB root 
assigned at the time that the module is being published as part of an 
RFC. 


This document lists the currently assigned rmon OIDs. It also 
describes the procedures and rules for new assignments and asks IANA 
to take over the responsibility for existing and future assignments. 


The current assignments are not all too logical. Initially normal 
MIB OIDs were assigned under rmon, but at a later time the WG used 
the rmon root OID to create new MIB modules underneath it. Some 
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people will claim ’an OID is just an OID’, and while this is true, it 
does not make things easier if the organisation of OIDs is not 
logical. However, we cannot change what has been assigned in the 
past. From now on, only MODULE-IDENTITY macro (MIB root) assignments 
will be made (by IANA) under the ’rmon’ node. Within a MIB module, 
the working group authors/editors can then assign their own OIDs 
according to normal procedures. 


2. Currently assigned OIDs under the rmon root 
At the time of this writing, the following OIDs have been assigned 
and IANA has picked up this information in their public registry of 
assigned values. They are listed as part of the already existing 
smi-numbers registry at: 


http://www.iana.org/assignments/smi-numbers 


..-mib-2.rmon (1.3.6.1.2.1.16) 


The assignments under ...mib-2.rmon were maintained by the RMONMIB 
Working Group until publication of RFC 3737. Some (early) 
assignments may not look all too logical. That is true, but that is 


history and cannot be changed. From now on, only MODULE-IDENTITY 
macro (MIB root) assignments will be made (by IANA) under the ’rmon’ 
node. 
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Key: nnn == { rmon nnn } 
nnn descriptor OID Type Document 
(0) rmonEventsV2 Notifications root [RFC2819] 
1 statistics OID [RFC2819] 
2 history OID [RFC2819] 
3 alarm OID [RFC2819] 
4 hosts OID [RFC2819] 
5 hostTopN OID [RFC2819] 
6 matrix OID [RFC2819] 
Y filter OID [RFC2819] 
8 capture OID [RFC2819] 
9 event OID [RFC2819] 
10 tokenRing OID [RFC1513] 
11 protocolDir OID [RFC2021] 
12 protocolDist OID [RFC2021] 
13 addressMap OID [RFC2021] 
14 nlHost OID [RFC2021] 
15 nlMatrix OID [RFC2021] 
16 alHost OID [RFC2021] 
17 alMatrix OID [RFC2021] 
18 usrHistory OID [RFC2021] 
19 probeConfig OID [RFC2021] 
20 rmonConformance OID [RFC2021] 
21 mediaIndependentStats OID [RFC3273] 
22 switchRMON M-I [RFC2613] 
23 apm M-I [RFC3729] 
24 available 
25 pmCapsMIB M-I (defunct) 
26 dsmonMIB M-I [RFC3287] 
27 interfaceTopNMIB M-I [RFC3144] 
28 reserved for sspmMIB M-I [..rmonmib-sspm-mib-nn.txt] 
29 hcAlarmMIB M-I [RFC3434] 
30 reserved for tpmMIB M-I [..rmonmib-tpm-mib-nn.txt] 
31 reserved for raqmon M-I [..rmonmib-raqmon-mib-nn.txt] 
32 reserved for raqmonDs M-I [..rmonmib-raqmon-pdu-nn.txt] 
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Key: xxx == { rmon.rmonConformance xxx } 


..-mib-2.rmon.conformance (1.3.6.1.2.1.16.20) 


XXX descriptor OID Type Document 
ile rmon2MIBCompliances OID [RFC2021] 
2 rmon2MIBGroups OID [RFC2021] 
3 smonMIBCompliances OID [RFC2613] 
4 smonMIBGroups OID [RFC2613] 
5 hcRMON M-I [RFC3273] 
6 hcRmonMIBCompliances OID [RFC3273] 
7 hcRmonMIBGroups OID [RFC3273] 
8 rmonMibModule M-I [RFC2819] 
9 rmonCompliances OID [RFC2819] 
10 rmonGroups OID [RFC2819] 
3. How to request a new assignment for a MIB module 


When anyone is writing a internet-draft for which a new assignment is 
needed/wanted under the rmon OID, then the proper way to do so is as 


follows: 
EXAMPLE-MIB DEFINITIONS ::= BEGIN 
IMPORTS 
rmon FROM RMON-MIB 


other imports 
exampleMIB MODULE-IDENTITY 
other normal MODULE-IDENTITY stuff 
::= { rmon nnn } -- IANA: please assign nnn 
-- RFC-Editor: replace nnn with IANA-assigned 
=> number and remove this note 
IANA will assign the number as part of the RFC publication process. 


4. Security Considerations 


This memo describes procedures for IANA assignment of OBJECT 
IDENTIFIER values, and has no impact on the security of the Internet. 
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5. IANA Considerations 


IANA has picked up the initial set of assignments and integrated them 
into the existing registry for smi-numbers at: 


http://www.iana.org/assignments/smi-numbers 

The list is presented in Section 2. 

IANA is requested to maintain this registry for future assignments. 

New assignments can only be made via Standards Action as described in 

[RFC2434]. 

IANA will assign the number as part of the RFC publication process. 
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to the rights, licenses and restrictions contained in BCP 78 and 
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This document and the information contained herein are provided on an 
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Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed 
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it 
represent that it has made any independent effort to identify any 
such rights. Information on the procedures with respect to 

rights in RFC documents can be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
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The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
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to implement this standard. Please address the information to the 
IETF at ietf-ipr@ietf.org. 
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